30 天到了。

第一天我寫下這段話：

這次鐵人賽對我來說，不只是完成 30 篇文章，更希望透過每天一步一步的累積，
真正理解 AI 是如何從「收到指令」走向「自主完成任務」。

今天來回答這個問題。

一、這 30 天走過的路

Day 1      前言：為什麼想做這個題目
Day 2-7    Python 基礎：變數、判斷、迴圈、List、Dict、Function
Day 8-11   穩固地基：例外處理、檔案、JSON、Class
Day 12-15  連上世界：環境變數、HTTP、天氣 API、Tool 封裝
Day 16-17  看見與記錄：資料分析、logging 與 trace
Day 18-20  AI 進場：第一次呼叫、Prompt 設計、結構化輸出
Day 21-22  轉捩點：Tool Use、工具註冊表
Day 23-26  架構思考：Workflow、控制流、自主的邊界、記憶
Day 27-29  整合專案：設計、實作、驗收
Day 30     回顧

從 print("Hello") 到一個會自己決定要查什麼、記得我不吃牛肉的助理。

二、那條線畫在哪裡

回到開頭的問題：AI 是怎麼從「收到指令」走向「自主完成任務」的？

我的答案是：它從來沒有真的「自主」，是我們設計的結構讓它看起來自主。

具體來說，有三個關鍵的轉折：

轉折一：輸出從「文字」變成「結構」（Day 20）

# 之前
"好的，我幫你記下明天下午三點跟客戶開會"

# 之後
{"action": "create_event", "title": "跟客戶開會", "date": "2026-10-04"}

當 AI 的輸出可以被程式讀懂，它的判斷就變成了控制流。

這是第一道門。在這之前，AI 只能產生給人看的文字；在這之後，它能觸發動作。

轉折二：結果可以回到模型手上（Day 21）

模型：「我想呼叫 get_weather」
  ↓
程式：實際執行，拿到結果
  ↓
程式：把結果傳回給模型
  ↓
模型：「根據這個結果，我下一步要…」

迴圈形成了。

前一步的結果影響下一步的決定，這就是「自主」的技術本質。它不是什麼神祕的東西，就是一個 while 迴圈加上把結果餵回去。

轉折三：迴圈的終止條件由模型決定（Day 22）

if response.stop_reason != "tool_use":
    return answer      # 模型說「我講完了」

在傳統程式裡，迴圈什麼時候結束是我們寫的。在 Agent 裡，是模型決定的。

這才是真正的分界線。

我們仍然設上限（max_turns、Budget），但在上限之內，何時停止是它說了算。

三、我學到最重要的幾件事

1. 大部分的「AI 問題」其實是工程問題

我原本以為做 Agent 的難點在於「怎麼讓 AI 更聰明」。實際做下來，卡住我最久的都是工程問題：

• 天氣 API 掛掉，整個流程崩潰 → 要做 required=False（Day 24）
• 對話越來越貴 → 要做歷史管理（Day 26）
• 不知道它為什麼這樣回答 → 要做 trace（Day 17）
• 工具參數填錯導致程式崩潰 → 要做 safe_run()（Day 15）
• 空資料讓程式炸掉 → 要統一回傳結構（Day 29）

模型本身很強。弱的是它周圍的那些程式碼。

而這些工程能力，Day 8 到 Day 17 就全部涵蓋了。那十天看起來跟 AI 無關，但它們才是 Agent 能不能穩定運作的關鍵。

2. 自然語言也是程式碼

這是最違反直覺的一課。

我一開始把 system prompt 當成「說明文字」，寫得很隨意。後來才發現，這些東西的影響力跟程式碼一樣大：

Day 29 那個「假裝設好鬧鐘」的 bug，修法不是改程式，是把 prompt 裡抽象的規則改成可執行的檢查步驟。

所以我現在會用對待程式碼的方式對待 prompt：版本控制、寫測試、記錄為什麼這樣改。

3. 錯誤訊息是給 AI 的 prompt

這是我覺得最有意思的發現。

# ❌ AI 不知道該怎麼辦
"查詢失敗"

# ✅ AI 知道可以重試
"查詢天氣逾時，請稍後再試"

# ✅ AI 知道不該重試，該問使用者
"找不到「東京」，本工具只支援台灣縣市"

# ✅ AI 知道要換個方式
"你已經用相同參數呼叫過兩次了，結果不會改變。請改用其他方式，或告訴使用者目前的困難。"

在傳統程式裡，錯誤訊息是給人看的。在 Agent 裡，錯誤訊息會直接進到模型的 context，影響它的下一步決策。

Day 29 的實測裡，add_todo 失敗了一次（模型給了「下週五」而不是日期格式），但它看到錯誤訊息後自己修正重試成功了。好的錯誤訊息讓 Agent 有自我修復的能力。

4. 能不用 AI 就不要用 AI

這個結論有點反高潮，但我覺得很重要。

Day 29 的實測數據：

差 130 倍。

而「列出待辦清單」這件事，用 Day 16 的排序加格式化就做得很好，根本不需要 AI。

所以我的原則變成：

先問「這件事一定要 AI 嗎」，再問「要用多聰明的 AI」。

Router 的設計（Day 23）就是這個原則的實踐——80% 的請求走便宜的路，20% 的長尾才交給 Agent。實測省了約 50% 成本。

5. 讓它說「我不知道」比讓它做事更難

模型很願意幫忙，願意到會腦補。

Day 29 那個鬧鐘的例子，它寧可說謊也要「幫上忙」。這不是它壞，是它被訓練成要有幫助。

所以我的 system prompt 裡，關於「不要編造」「不要假裝」「不確定就問」的規則，比關於「要做什麼」的規則還多。

一個可靠的助理，誠實比能幹重要。

6. 人要留在迴圈裡

Day 25 我寫過這句話，現在更確定：

確認機制不是「因為 AI 不可靠」，而是「因為那是我的事」。

如果 Agent 刪掉了我的資料，我不能說「這是 AI 決定的」。那是我的資料，我的責任。

技術會進步，模型會更可靠。但「不可逆的決定要有人負責」這件事，我覺得不會因為模型變強就改變。

四、如果重來一次，我會怎麼做

做得對的：

• ✅ 從 Python 基礎開始。很多人會覺得前七天「太淺」，但 Day 8-17 的工程能力全部建立在那上面。
• ✅ Day 17 就做 trace。這是整個系列最值得的投資。沒有它，Day 29 那個「假裝設鬧鐘」的問題我根本查不出來。
• ✅ Day 27 先定義「完成」。十條驗收標準讓我知道什麼時候該停手。

會改的：

• ❌ Day 15 的工具設計應該更早。我在 Day 21 才發現 Day 15 寫的 description 有多重要，回頭改了好幾次。
• ❌ 測試應該更早開始。Day 29 才發現的空清單 bug，如果 Day 16 就寫測試，當場就會抓到。
• ❌ 成本統計應該從 Day 18 就做。我到 Day 29 才知道各路徑的成本差 130 倍，如果更早知道，架構會不一樣。

五、這 30 天的成果

一個可以每天用的生活助理：

life-assistant/
├── 10 個工具（天氣、待辦、時間、記憶、計算）
├── 3 個 Workflow（簡報、天氣、待辦）
├── 1 個 Agent 迴圈（含預算、確認、trace）
├── 2 層記憶（對話歷史、長期偏好）
└── 完整的基礎設施（設定、日誌、追蹤、測試）

實測三天：45 次請求，$0.94，沒有崩潰過。

我現在每天早上真的會打開它。這點對我來說比程式碼本身更有價值——它不是一個 demo，是一個我會用的東西。

六、接下來可以往哪走

給想繼續的人（包括我自己）幾個方向：

短期（一兩週能做完）

因為架構是分層的，這些改動都不會動到核心邏輯。

中期（需要學新東西）

我自己最想做的是評估。這 30 天我都是靠手動測試和直覺判斷「好不好」，但這不可持續。有一組自動化的評估集，才能放心地修改 prompt。

長期思考

不是技術問題，但值得想：

• 責任邊界：Agent 做錯事，誰負責？
• 資料隱私：長期記憶存了什麼？誰看得到？
• 依賴風險：如果我每天依賴它，它掛掉那天怎麼辦？
• 人的角色：當 AI 能做越來越多事，人該做什麼？

七、給想開始的人

如果你也想做類似的東西，我的建議：

1. 不要一開始就用框架

LangChain、LlamaIndex 這類框架很強大，但如果你不知道底下發生什麼事，出問題時完全束手無策。

Day 21 那三十幾行的 Agent 迴圈，是整個系列最有價值的程式碼。先自己寫一遍，再去用框架，你會知道框架在幫你做什麼。

2. 從一個你真的會用的東西開始

我選生活助理，是因為我每天早上真的想知道要不要帶傘。

如果做一個你不會用的東西，你不會發現那些只有真實使用才會遇到的問題（空清單、API 掛掉、第十輪對話變貴）。

3. 把基礎打好

例外處理、檔案、JSON、logging——這些看起來跟 AI 無關的東西，才是 Agent 能不能穩定運作的關鍵。

4. 從最簡單的開始

能用 if-else 嗎？→ 用
不行的話，能用單次 AI 呼叫嗎？→ 用
不行的話，能用固定 Workflow 嗎？→ 用
真的都不行 → 才用 Agent

5. 記錄一切

Day 17 的 logging 和 trace，是我整個系列最推薦的投資。

八、最後

第一天我說：

那麼，就從 Python 開始吧。

30 天後，我想說的是：

AI Agent 不是魔法。

它是 while 迴圈、try/except、json.loads()、一個 HTTP 請求、還有一些寫得夠清楚的文字。

這 30 天最大的收穫，不是學會了怎麼用 AI，而是理解了AI 在一個系統裡的位置——它很擅長理解語意和處理模糊，但它需要一個穩固的工程結構把它撐起來。

那個結構是我們寫的。

也因為這樣，「自主決策」這四個字，其實一直都是人在決定的——我們決定給它什麼工具、什麼資訊、什麼邊界、什麼時候該停。

AI 負責在我們設計的空間裡做選擇。設計那個空間，才是我們的工作。

感謝每一位看到這裡的人。

這 30 天不是終點。程式碼還會繼續改，助理還會繼續用。

如果你也想開始，現在就是好時機。

那麼，就從 Python 開始吧。

— pzhiqi，2026.10.14

完整目錄